Save card
Request for the gateway to store card information against a token, where you provide the token id.
Note: The behaviour of this call depends on two aspects of your token repository configuration: Token Generation Strategy (either Merchant-Supplied, Random or Preserve 6.4) and Token Management strategy (Unique Card or Unique Token). For more information, see How to Configure Tokenization. Your Token Generation Strategy and Token Management Strategy will be configured by your gateway provider for you. For all repository configurations, you can use this call to update the data for a token. If you use a Merchant-Supplied generation strategy, you also use this call to create the token. However, to maintain the repository rules, the gateway will reject your request and generate an error if:- You are using a Preserve 6.4 repository and your request would change the card number. If we did not, we would break the 6.4 preservation rule.
- You are using use a Unique Card Number repository and you attempt to update this token to a card number that is already assigned to another token. If we did not, we would have two tokens for the same card number, which would break the uniqueness rule.
Authentication Copied to clipboard
This operation requires authentication via one of the following methods:
- Certificate authentication.
-
Basic HTTP authentication as described at
w3.org.
Provide 'merchant.
<your gateway merchant ID>' in the userid portion and your API password in the password portion.
Request Copied to clipboard
URL Parameters Copied to clipboard
Alphanumeric + additional characters
REQUIRED
The unique identifier issued to you by your payment provider.
This identifier can be up to 12 characters in length.
Data may consist of the characters 0-9, a-z, A-Z, '-', '_'
Min length: 1 Max length: 40Alphanumeric
REQUIRED
Uniquely identifies a card and associated details.
Data may consist of the characters 0-9, a-z, A-Z
Min length: 1 Max length: 40Fields Copied to clipboard
Enumeration
OPTIONAL
The strategy that should be used to verify the card details on the request.
If not provided the verification strategy on the merchant profile will be used to verify the card details on the request.
Used to nominate which type of Card Verification to use when card details are stored in the token repository. This setting overrides the default settings in Merchant Manager.
Value must be a member of the following list. The values are case sensitive.
ACQUIRER
Verifies that the card is valid by performing an Authorize transaction for an nominal amount (e.g.$1.00)
BASIC
Verifies the card number is valid and that the card number falls within a valid BIN range
NONE
No verification of the card details are performed
String
OPTIONAL
A transient identifier for the request, that can be used to match the response to the request.
The value provided is not validated, does not persist in the gateway, and is returned as provided in the response to the request.
Data can consist of any characters
Information about the payment type selected by the payer for this payment and the source of the funds.
Depending on the payment type the source of the funds can be a debit or credit card, bank account, or account with a browser payment provider (such as PayPal).
For card payments the source of funds information may be represented by combining one or more of the following: explicitly provided card details, a session identifier which the gateway will use to look up the card details and/or a card token. Precedence rules will be applied in that explicitly provided card details will override session card details which will override card token details. Each of these may represent partial card details, however the combination must result in a full and complete set of card details. See Using Multiple Sources of Card Details for examples.
Information about the source of funds when it is directly provided (as opposed to via a token or session).
For browser payments, the source of funds details are usually collected from the payer on the payment provider's website and provided to you when you retrieve the transaction details (for a successful transaction). However, for some payment types (such as giropay), you must collect the information from the payer and supply it here.
Details as shown on the card.
Expiry date, as shown on the card.
Digits
REQUIRED
Month, as shown on the card.
Months are numbered January=1, through to December=12.
Data is a number between 1 and 12 represented as a string.
Digits
REQUIRED
Year, as shown on the card.
The Common Era year is 2000 plus this value.
Data is a string that consists of the characters 0-9.
Digits
OPTIONAL
Credit card number as printed on the card.
Data is a string that consists of the characters 0-9.
Digits
OPTIONAL
Card verification code, as printed on the back or front of the card.
Data is a string that consists of the characters 0-9.
ASCII Text
OPTIONAL
Session carrying the card details to be used.
Data consists of ASCII characters
Alphanumeric
OPTIONAL
Uniquely identifies a card and associated details.
Data may consist of the characters 0-9, a-z, A-Z
Enumeration
REQUIRED
The payment method your payer has chosen for this payment.
Value must be a member of the following list. The values are case sensitive.
CARD
The customer selected to pay using a credit or debit card. The payer's card details must be provided.
Upper case alphabetic text
OPTIONAL
The currency which should be used for acquirer card verification.
Not required for basic verification.
Data must consist of the characters A-Z
Response Copied to clipboard
Fields Copied to clipboard
String
CONDITIONAL
A transient identifier for the request, that can be used to match the response to the request.
The value provided is not validated, does not persist in the gateway, and is returned as provided in the response to the request.
Data can consist of any characters
Enumeration
CONDITIONAL
Summary of the success or otherwise of the Save operation.
Value must be a member of the following list. The values are case sensitive.
BASIC_VERIFICATION_SUCCESSFUL
The card number format was successfully verified and the card exists in a known range.
EXTERNAL_VERIFICATION_BLOCKED
The external verification was blocked due to risk rules.
EXTERNAL_VERIFICATION_DECLINED
The card details were sent for verification, but were was declined.
EXTERNAL_VERIFICATION_DECLINED_AUTHENTICATION_REQUIRED
The card details were sent for verification, but were declined as authentication required.
EXTERNAL_VERIFICATION_DECLINED_EXPIRED_CARD
The card details were sent for verification, but were declined as the card has expired.
EXTERNAL_VERIFICATION_DECLINED_INVALID_CSC
The card details were sent for verification, but were declined as the Card Security Code (CSC) was invalid.
EXTERNAL_VERIFICATION_PROCESSING_ERROR
There was an error processing the verification.
EXTERNAL_VERIFICATION_SUCCESSFUL
The card details were successfully verified.
NO_VERIFICATION_PERFORMED
The card details were not verified.
Enumeration
ALWAYS PROVIDED
A system-generated high level overall result of the Save operation.
Value must be a member of the following list. The values are case sensitive.
FAILURE
The operation was declined or rejected by the gateway, acquirer or issuer
PENDING
The operation is currently in progress or pending processing
SUCCESS
The operation was successfully processed
UNKNOWN
The result of the operation is unknown
Details about the source of the funds for this payment.
The details of the source of funds when they are directly provided as opposed to via a token or session.
Details as shown on the card.
Expiry date, as shown on the card.
Digits
ALWAYS PROVIDED
Month, as shown on the card.
Months are numbered January=1, through to December=12.
Data is a number between 1 and 12 represented as a string.
Digits
ALWAYS PROVIDED
Year, as shown on the card.
The Common Era year is 2000 plus this value.
Data is a string that consists of the characters 0-9.
Masked digits
CONDITIONAL
The account number embossed onto the card.
The number will be masked according to your masking settings and how you authenticated your call to the API.
If you authenticated using certificate authentication, then your masking settings will be used. This allows you to return unmasked card numbers if you have chosen not to apply masking.
If you authenticated to the API by a means other than certificate authentication, then the card number will be returned with your masking settings or 6.4; whichever is more restrictive for example, 000000xxxxxx0000.
Data is a string that consists of the characters 0-9, plus 'x' for masking
Enumeration
CONDITIONAL
The card scheme e.g. AMEX, DISCOVER, DINERS_CLUB, JCB, MASTERCARD, UATP VISA.
Only card schemes which can be identified by distinct BIN ranges are included in this list. All other card schemes are included under "Other"
Value must be a member of the following list. The values are case sensitive.
AMEX
American Express
CHINA_UNIONPAY
China UnionPay
DINERS_CLUB
Diners Club
DISCOVER
Discover
JCB
JCB (Japan Credit Bureau)
MASTERCARD
MasterCard
OTHER
The scheme of the card used in the transaction could not be identified.
RUPAY
RuPay
UATP
UATP (Universal Air Travel Plan)
VISA
Visa
Enumeration
CONDITIONAL
The payment method your payer has chosen for this payment.
Value must be a member of the following list. The values are case sensitive.
CARD
The customer selected to pay using a credit or debit card. The payer's card details must be provided.
Alphanumeric
CONDITIONAL
Uniquely identifies a card and associated details.
The format of this token id depends on the Tokenization Strategy configured for the merchant:
- RANDOM_WITH_LUHN: Token is 16 digits long, starts with 9, and is in the format of 9nnnnnnnnnnnnnnC, where n represents any number, and C represents a check digit such that the token will conform to the Luhn algorithm.
- PRESERVE_6_4: The first 6 and last 4 digits of the token are the same as the first 6 and last 4 digits of the provided card number, middle digits are randomized, the token id does NOT conform to Luhn algorithm.
- MERCHANT_PROVIDED: The merchant must supply the token id in the Save request
Data may consist of the characters 0-9, a-z, A-Z
Errors Copied to clipboard
Information on possible error conditions that may occur while processing an operation using the API.
Enumeration
Broadly categorizes the cause of the error.
For example, errors may occur due to invalid requests or internal system failures.
Value must be a member of the following list. The values are case sensitive.
INVALID_REQUEST
The request was rejected because it did not conform to the API protocol.
REQUEST_REJECTED
The request was rejected due to security reasons such as firewall rules, expired certificate, etc.
SERVER_BUSY
The server did not have enough resources to process the request at the moment.
SERVER_FAILED
There was an internal system failure.
String
Textual description of the error based on the cause.
This field is returned only if the cause is INVALID_REQUEST or SERVER_BUSY.
Data can consist of any characters
String
Indicates the name of the field that failed validation.
This field is returned only if the cause is INVALID_REQUEST and a field level validation error was encountered.
Data can consist of any characters
String
Indicates the code that helps the support team to quickly identify the exact cause of the error.
This field is returned only if the cause is SERVER_FAILED or REQUEST_REJECTED.
Data can consist of any characters
Enumeration
Indicates the type of field validation error.
This field is returned only if the cause is INVALID_REQUEST and a field level validation error was encountered.
Value must be a member of the following list. The values are case sensitive.
INVALID
The request contained a field with a value that did not pass validation.
MISSING
The request was missing a mandatory field.
UNSUPPORTED
The request contained a field that is unsupported.
Enumeration
A system-generated high level overall result of the operation.
Value must be a member of the following list. The values are case sensitive.
ERROR
The operation resulted in an error and hence cannot be processed.